home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19980901-19981211
/
000221_news@newsmaster….columbia.edu _Tue Oct 27 11:08:04 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-12-10
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA18683
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 27 Oct 1998 11:08:04 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA11257
for kermit.misc@watsun; Tue, 27 Oct 1998 11:08:03 -0500 (EST)
Path: news.columbia.edu!panix!logbridge.uoregon.edu!xmission!news.cc.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Q. about running kermit over a proprietary transmission network
Message-ID: <NnDzx8U6YImc@cc.usu.edu>
Date: 27 Oct 98 08:13:02 MDT
References: <713hfu$3na$1@nnrp1.dejanews.com>
Organization: Utah State University
Lines: 75
Xref: news.columbia.edu comp.protocols.kermit.misc:9421
In article <713hfu$3na$1@nnrp1.dejanews.com>, tony_w_k_wu@my-dejanews.com writes:
> Hi
>
> I want to run kermit over 57600 baud async. serial through a
> proprietary transmission system/network and comes out serially
> into another device. The typical transfer file size are
> about 300Kbyte. (up to 1 -2 Mbyte max)
>
> The proprietary transmission system is a CSMA/CD kind of LAN.
> Its speed is around 44Kbaud and it is NOT noisy.
> Note: the proprietary transmission system is about 10-20%
> slower than the serial link.
> It support :
> a) UNACK type of transmission of data packet with 88bytes data
> payload. (quick and no guarantee of delivery)
> latency is about 40 ms per 88bytes data packet.
>
> b) ACK type of transmission with segmentation/reassembly capability
> and arbitrary data length. (guarantee delivery)
>
> I need to build some software in the proprietary transmission system
> to convert the kermit over serial into
> either a) or b) type of transmission format. (or even combination of
> both)
>
> Note: there is no HW flow control ie RTS/CTS between the serial
> link
> Note: XON and XOFF is delivered transparently to the target device.
>
> Original thought is to build something extremely simple base on
> a) type of transmission.
> With a scheme like the follow:
> send a packet if I receive 88bytes serially or I have not
> send a packet in last 20ms and send whatever number of bytes
> I have received.
>
> Alternatively,
> I can look at the kermit initialization and negotiation sequence
> to figure out the packet length, window size. Look for the ^A and
> EOL to delimit each packet. And pack each kermit packet into
> type a) or type b) transmission adaptively. e.g. ACK/NAK kermit packet
> on type a) and data packet on type b).
>
>
> What do you think about the 2 schemes? Would I be able to gain any throughput
> improvement with the alternative scheme? How would you configure the window
> size and packet size in kermit to maximize throughput? Any thing I should
> take special care of when I am building something described above? Any other
> ideas to get the max througput?
-------
The Kermit protocol presumes "the wire" is noisy, lossy, and generally
anxious to destroy data. Thus Kermits provide error checking, retries,
timeouts, sequence numbers, and selective repeat sliding windows. All but
the last are requirements for a robust protocol independent of the quality
and delay of "the wire."
If you add reliability (point to point low level ACKs and retries)
to your wire (speaking algorithmically) then that reliability introduces
time delays. Those delays can compete with what Kermit does, and it is
not simple to predict the maximum throughput combination.
What your wire lacks is flow control, the killer of many comms links.
Fix that and let the high level protocols, such as Kermit, take care of
recovering from missing data.
It is a very un-good idea to try spoofing protocols by providing
synthetic ACKs and so on. The wire lies like a bandit because while ACKing
to the Kermit sender it has in fact not delivered the data to the far
end. And your scheme will be out of date as the protocol details evolve.
Telebit tried this with their modems and the results were not worth the
effort. I shudder each time I see an outfit try faking things this way.
One guesses you are playing with a radio link, a cell phone or
similar spread spectrum arrangement. Just get flow control implemented
so that overrun data loss is miminised at the interfaces to the high level
protocols. The protocols will take care of the rest, and one then tunes
them based on particular link characteristics.
Joe D.
Joe D.